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Abstract 


This paper describes the design and verification strategies 
used to create a third generation symbolic processor = 
timized for the Lisp language. The approach is unique in 
that it is probably the first large scale application of object 
oriented programming techniques to a production IC design 
problem. _These techniques have yielded not only high 
productivity in the construction of the design tools but also 
clearly demonstrate the designer productivity available 


through the application of a well i 
design tools, well integrated set of VLSI 


1. Introduction 


Design and verification of complex architectures must occur 
at several widely separated levels of abstraction including 
the virtual machine, instruction set, architectural, gate and 
circuit levels. During the design, congruent descriptions 
must exist in the behavioral, schematic and layout domains. 
Many proposals have been made for dealing with the diverse 
levels of detail evident in these various design domains. Our 
common denominator is the Lisp language and the uniform 
virtual address space provided by the Lisp machine operat- 
ing system combined with an object-oriented electronic 
design system called NS. The result is no HDL but Lisp, 
no data files but Lisp data objects and no raw test vectors 
but Lisp code. We believe this approach is clean, easy to 
customize and extend, and requires little maintenance as 
Lisp is a commercially supported language with excellent 
compilers, editors, debuggers and advanced run-time en- 
vironments. 


NS [1] is a design system written in New Flavors, an object- 
oriented extension of Common-Lisp. Diagram objects and 
electrical network objects are the two basic object types 
upon which a wide variety of tools are based. A diagram ob- 
ject, for instance, might be a schematic which is comprised 
of lines, named terminals and hierarchical instances. Ex- 
traction is performed by traversing the diagram object. The 
result of extraction is an electrical network which consists 
of nodes, transistors and other primitive circuit elements. A 
switch-level simulator works by traversing the network ob- 
ject. Message passing between diagrams and networks yields 
an extensible design system with an effective user interface. 


The implementation of the Ivory single-chip Lisp 
microprocessor provided some interesting VLSI design trade- 
offs. It was undertaken by a small team of people, had to 
be completed in a short time and had to proceed in parallel 
with the refinement of the architecture. This paper sum- 
marizes the set of tools and design approaches used in the 
development of the chip. Where possible we will show how 
Lisp was used as a specification or verification language. 


CH2473-7/87/0000/0506$01.00 © 1987 IEEE 


2. Architectural Design 


2.1 Architectural Simulation 


design level models the I-machine (the 
aioe geothes siag Rey the Ivory chip) by reflecting the 
state of the architecturally-defined stacks and _ registers. 
This level of design is used to verify the virtual machine 
architecture and gather architectural statistics. 


irtual machine simulators were written to model this 
joy at the machine. The first was written by the VLSI 
group, while the second was written later in the design 
cycle by the software development group. Both use a fairly 
straightforward implementation of an instruction set 
emulator. This consists of a set of data structures modeling 
the relevant machine state (in this case, the system’s stacks 
and stack pointers) and a Lisp routine corresponding to 
each instruction which modifies the core data structures to 
reflect the effect of the instruction. The first simulator is 
2500 lines of Lisp and runs at 2000 instructions per second. 


The following represents the specification of the ADD in- 
struction at this level of design. 


(defemulator add operand 
(mul tiple-value-bind 
(first-operand second-operand) 
(fetch-two-operands operand) 
(stack-push (+ first-operand second-operand) ))) 


2.2 Behavioral Simulation 


The behavioral simulator was built using the object-oriented 
programming facilities provided by the Lisp Machine en- 
vironment. The system is decomposed into approximately 
20 modules, each of which is modeled as an instance of 
some class of objects. Each instance maintains private 
state. Attached to each class was a set of methods for im- 
plementing generic behavior in a manner suitable for ob- 
jects of that class. Each module defines a set of I/O signals 
that constitute a module’s communication ports. These 
specify the ports to be used in the circuit design. The fol- 


lowing specifies an adder with inputs opi and op2 and out- 
puts EXTERNAL-BUS. 


(defmodule (adder ivory) 
:local-state () 
:local-phase-1-registers () 
:local-phase-2-registers () 
:phase-1-registers () 
:phase-2-registers () 
:phase-1-inputs () 
:phase-1-outputs () 
:phase-2-inputs (op1 op2) 

:phase-2-outputs (external-bus) 


(Gefaction (aditer 
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Figure 1. 


Functional Simulator Window Interface 


An assembler supports the develo 
module. The following represents t 
for the ADD instruction: 


pment of the microcode 
he microcode specification 


(definstruction add 

(parallel 
(check-arithmetic-operands operand-1 operand-2) 
(pop2push (+ operand-1 operand-2) ) 
(enable-overflow-exception) 
(next-instruction))) 


The simulator and Lisp description of Ivory total 9000 lines 
of code including comments. The simulator runs at about 30 
instructions per second. 


What is novel about this simulator is its implementation 
technology and its relationship to its surrounding environ- 
ment. Since the simulator is part of a Lisp environment, it 
can write and execute other Lisp programs which execute 
within the same environment. — Furthermore, these 
procedures can be individually modified and dynamically 
linked into the environment without interrupting normal ex- 
ecution. Therefore, there is no need to create a new HDL 
and implement the standard variety of control structures re- 
quired within it. Instead, the simulation routines are normal 
Lisp procedures with access to the full richness of the Lisp 
programming environment. 
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3. Structural Design 


The NS interactive editor provides for the capture of 
schematics and schematic-icons A menu-driven generator 
builds most common icons automatically. Figure 2 shows a 
Yiew of the echematic editor with two views of a schematic. 


Schematic Editor Interface 


Figure 2. 


A designer may enter schematics by the normal approach of 
graphical editing or may use a Lisp HDL to allow rapid and 
accurate entry of control logic. In the latter case, code can 
be for the most part taken directly from the behavioral 
simulator. The following description is representative: 


(def-std-cell-schematic (“simple-example” 
:inputs(p q a b) 
:outputs(z wW)) 


(setq z (if (and p q) 
a 


b)) 
(setq W (not (and a b) (or p q)))) 


When compiled, the logic is simplified and a rule-based 
technology selector optimizes the circuit used by choosing 
gates, merging gates and eliminating unnecessary inverters. 
A simple pattern matching language is used to apply the 
rules. The rules are augmented as different situations arise 
during the course of the design. The following represent 
rules for recognizing AOI’s. 


(define-eqn-transformer AOI (NOR (AND b c d) a) 
(AND3-NOR2 a b c d)) 


(def ine-eqn-transformer AOI (NOR (NOR a b) 


(NOR c @)) 
(OR2-OR2-AND2 a b c d)) 


(def ine-eqn-transformer AOI (AND (NOT (NOR a b)) 


(NOT (NOR c d))) 
(OR2-OR2-AND2 a b c d)) 


These generally have a higher likelihood of being accepted 
because they make the most efficient use of area. Different, 
but equivalent logic expressions can map onto the same 
AOI. In all cases, the canonical expression represented by 
the nested ANDs, ORs and NOTs is converted to a specific 


gate (ie. an OR2-OR2-AND2) which is in the standard cell 
library. 


Some rules implement demorganizing that 


cial gates (ie. XORs), while others reco; 


up rules (i.e. it is advantageous to redui 
a latch). 


t is specific to spe- 
gnize circuit speed- 
ce the setup time to 


(def ine-eqn-transforner INVERSE (XOR a (NO b)) 
& ) ( ( ) 


Finally, less desirable rules are attem i 
; pted which try to 
reduce the placement problem by assigning gatestineettent 


chains to a single standard-cell thus reduci h 
erotics 5 ucing channel rout- 


(def ine-eqn-transformer IMPLOOE 


NOT 
(ANO a b)) (NOT (NANO a b)) 


The designer can specify named gates (ie. NAND5, NOR2) 
thereby forcing a specific implementation. 


Although the designer does not have to be aware of the un- 
derlying object-oriented data-base to complete designs, a 
knowledge of these details can aid productivity. Most of our 
designers can write simple data-base query programs such 
as the following Lisp program which calculates the total in- 
ternal capacitance of a network. 


(defmethod (internal-capacitance rsim-network-mixin) () 
(loop for node in nodes 
unless (or (eq node gnd) 
(eq node vdd)) 
sum (node-capacitance node))) 


A electrical rules checker is used 


; 4 to check port names, port 
directions, 


bus widths and other structural rules. 


4. Physical Design 


All of the chip cell designs (including pads) are specified in 
the virtual grid symbolic layout style either with the NS 
graphics editor (color or monochrome) or via Lisp 
procedures. This is a process independent layout style in 
which the designer does not have to deal with geometric 
design rules. Rather transistors and wires are placed on a 
coarse grid in a relative manner to each other. Cell designs 
are compacted or spaced according to a target technology 
description. The design style can deal with large pitch- 
matched cells of the order of 50K transistors. Our ap- 
proaches to this are summarized in [2]. 


A standard cell layout system automatically generates sym- 
bolic layout from control schematic diagrams with the op- 
tion of using port locations specified by the mask-outline. 
Both min-cut and thermal-annealing [3] approaches have 
been used. Min-cut is much faster but thermal annealing 
has a slight density edge. We expect the min-cut density 
will improve and will become the automatic layout style of 
choice. The aspect ratio of the module may be specified to 
allow area tuning. Figure 3 shows a typical virtual grid 
standard cell layout with the contents of some cells dis- 
played. 


Data paths are constructed manually. Basic cells such as 
registers, muxes and adders are provided in a data-path 
standard cell library. To improve productivity, liberal use is 
made of generators [4]. The following generator horizontally 
abuts three cells and raises the instance ports to this level 
of the hierarchy. 


(defaspect-generator (data-path :Virtual-grid) (flag) 
(HORI ZONTALLY-ABUT ‘module-a 
(if flag 
‘module-b 
*module-d) 
*module-c) 
(import-ports-oan-edges) ) 
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Pent ees ree on 


Figure 3. A Symbolic Standard Cell Layout 


When all modules have been designed symbolically and com- 
pacted, the NS interactive editor is used to specify a slicing 
style floorplan [5)(6]. Using the connectivity of the cor- 
responding schematic, this floorplan is used as the basis to 
automatically place and route the entire chip. A global 
router first assigns nets to the routing channels. When this 
is complete, modules are composed according to the floor- 
plan composition ordering. As they are connected, power, 
ground and clocks are also routed. This chip composition 
takes 2 hours to run for the complete Ivory chip. At early 
stages of design, partial floorplans can be constructed using 
estimates of block sizes. The following specifies the 
"example" module which has an estimated size of 250u by 
300u and has the inputs entering on the top and the out- 
puts exiting on the bottom. 


(def-mask-outline example (258 300) 
(:top “s<3:@8>" 
memory-write-pending 
bus-master-pin) 
(:bottom mew mcr mcrw)) 


Figure 4 shows the floor-plan of Ivory. 


A network comparison program is able to compare any two 
extracted networks (ie. from  virtual-grid layouts, 
schematics, mask layouts and vendor net-list files)[7]. Inter- 
active feedback is provided to identify suspicious nodes. No 
node names are necessary. 


A fast interactive DRC is provided for final mask artwork 
checks. 


A Floorplan View of Ivory 


Figure 4. 


5. Simulation 


5.1 Circuit Simulation 


A switch-level simulator with timi 
; 1 timing (RSIM)[8] was used to 
pei oo te gate and switch level circuit simulation re- 
Gir fenicn oF mene being spp ayiend for fast simulation, 
5 has t ii i i 
models in the following mney @ RAM): EE STN, 


(def functional-model cache 
:inputs (“addr<6:Q>" 
~row-enable 
write 
aiheide Pee peel 
:local-state ieee Ne ae 
rinitform 


memory 


(make~array 128 :initial-element ‘x))) 


:delays ((row-enablel —) data : 

:timing-constraints renee eee 
((addr ~ Pcatior :setup 16) 
(write-data > write :setup 15)) 


:model (cond 
((eq] addr *x) 
(setq data 'x)) 
((eql write 1) 
(setf (aref cache-array addr) 
write-data) 
(setq data write-data)) 
((eq] write @) 
(setq data 
(aref cache-array addr))))) 


Access to the RSIM simulator is available in parallel either 
via Lisp code that can set, read and compare values on a 
circuit node, or via mouse clicks on a schematic displayed in 
the graphics editor window. A hierarchical schematic can be 
traversed using PUSH/POP commands. The right window 
in Figure 2 displays the result of clicking near nodes. Test 
programs written in Lisp use a protocol consisting of three 
generic functions: 


© VALUE, which returns the value of a node, 
© SET-VALUE, which sets the value of a node, and 


© sIM-STEP, which propagates all changes through the net- 
work until no further changes occur. Optional ar- 
guments to SIM-STEP can specify the length of the 
simulation period. 


The normal Lisp-machine operating system features such as 
breakpointing, incremental compilation and function restart, 
along with the scope-probe capabilities of the NS design sys- 
tem, create an extremely powerful verification capability 
with a fast edit/compile/debug loop. This interactive circuit 
debugging capability is available on either schematics, sym- 
bolic layouts, or mask layouts. 

iled circuit level, SPICE [9] was used to verify 
pets gece of the design, such as adder speed and 
memory timing. An interactive interface is provided to 
SPICE which can be run locally on the Lisp machine or 
remotely over the network. Figure 5 shows a typical SPICE 
interaction session. 
To give some idea of the extensibility of NS, an experimen- 
tal timing simulator mode based on backward Euler integra- 
tion [10][11] was added to NS in a matter of a morning by a 
designer. We intend to incorporate parallel fault simulation 
into RSIM in the future, but it will probably take more than 


a morning. 
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Figure 5. A SPICE window view of a module 


5.2 Hardware Simulation Acceleration 


Although RSIM is relatively fast (of the same order of speed 
as current software logic simulators), the size of some 
modules (and certainly the whole chip) results in simulation 
times beyond realistic limits. A number of methods are 
available to solve this problem, including operating one 
module at a time at the switch level while the others 
operate at the functional level. The solution we adopted 
was to invest in a hardware simulation accelerator. With a 
moderate software effort, we were able to create an inter- 
active environment for the engine that is identical to the in- 
teractive RSIM environment. The accelerator is currently 
the only method of simulating the entire chip at a suf- 
ficiently low level to give the chip designers confidence in 
the transistor-level design. The simulation speed is roughly 
10 instructions a minute. 


Apart from a UNIX™ server and a Lisp-machine server re- 
quired to operate a network command protocol, the most 
significant piece of software is a "gate-recognizer." To 
maximize modeling element use in the accelerator, all 
groups of transistors are converted to logic gates, unidirec- 
tional switches, or (if unavoidable) bidirectional switches. 


6. Design Verification 


6.1 Functional Comparison 


The consistency of the architectural and behavioral 
simulators is verified by applying a large set of test 
programs to each simulator and checking for consistency ac- 
cording to an instruction-set architecture specification. Com- 
paring the behavioral simulator and the circuit data-base 
can be performed on a signal by signal basis as the be- 
havioral simulator is used to specify the modularity and 
communication between modules of the chip. 


As both the behavioral simulator and RSIM i 

b I : were imple- 
mented using the object-oriented programming facilities of 
the Lisp machine, one can pass common messages to both 
simulators to achieve the required behavior. 


During verification, sET-vALUE messages are 

the behavioral simulator and RSIM. Beet” tories: 
simulator takes the appropriate action to set internal node 
toa particular value. This is achieved using a “forwardi : 
network" which takes a list of two networks, one the RSIM 


in each simulator. Thus 


(Gefeetnad (sety forward'mg-netsark) (nece valve) 
(set-velus ¢sia-networs mode value) 
(set-velue Gamevtora! -aode! rode velue)) 


As the functional simulator works with a two-phase clock, » 
function is written to emulate the clocks for the RSIM 
simulation A simple version of this would look as follows 


(defmetnhed (siaulate-pmase-1 rs!a-network-elxin)() 
(set-velue self ‘pnt 1) 
(sta-step self) 
(set-value self ‘pnt @) 
(sim-step self)) 


This message is applied to both networks to advance 
through a phasel clock cycle. The following forwarding net- 
work function calls both phasel execution functions: 


(defmethod (phase! forwarding network) () 
(simul ate-phase-1 rsia-network) 
(stmulate-phase-1 behaviora)-mode))) 


The vERiry command operates by asking the two simulators 
for values and then comparing the results. If the results 
disagree, a debugging session with the user is initiated. 


The following represents a simple test program. 


(declare-bus ‘op! 32) 
(declare-bus ‘op2 32) 
(declare-bus ‘external-bus 32) 


(defun cospare-adder-ops (op1 op2) 

(phase1) 

(setv ‘opi op! ) 

(setv ‘op2 op2 ) 

(phase2) 

(verify ‘external -bus) ) 
Such programs are written by designers to test the 
functionality of individual modules. 


To provide higher level tests, a spy strategy was developed. 
With this facility, the complete behavioral simulator could 
be exercised by Lisp test programs. Arbitrary collections of 
modules can be grouped together (to model physical layout 
groupings) and their collective inputs and outputs monitored 
to provide a trace history of the boundary signals. The 
storage of the history allows both interactive and batch 
simulation. RSIM simulation code consisting of sETV and 
VERIFY statements, is generated from the history. This code 
was then applied directly to the extracted network with any 
discrepancies detected by VERIFY errors. 


The SPY code was extended to allow interfacing to an en- 
gineering tester. This allows interactive debugging of tests 
in an engineering environment that was closely linked to 
the program development environment of the Lisp machine. 


6.2 Timing Analysis 


A timing analyzer based on finding critical paths through 
transistor networks was implemented based on Crystal[(12). 
It was subsequently rewritten to incorporate ideas from 
Leadout [13]. The timing analyzer heuristically determines 
directions on bidirectional devices that cause loops in the 
circuit [14]. Support for functional models (using RSIM 
functional models) is also provided. 
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for plotting the actual c 

may be used with the circuit. Provisson 36 made for blocking 

ia the RSIM inte ae ee tia sizes and 

tance may be ¢ he timing results 

calcu copectinrecnensall. On Ivory (13K transistors and 

calcwtmal enodels for BOM and RAM) it takes 2 hours (on a 

Symbolics 3640 Lisp machine) to find all clocking con- 
straints. 


7. Version Control 


i mplex design involving a team of people, 
Dascabee bills be incorporated into a system to prevent the 
inadvertent inclusion of erroneous design data. Apart from 
NS support for the update of stale data libraries, we also 


implemented a change control system called the Manage- 


ment System. . 
During the design, specific verification steps have to be run 
on each module. For instance, & standard cell logic block 
has to be electrical rule checked, port checked, simulated, 
auto-placed, compacted, net-compared and the mask descrip- 
tion saved. For each different kind of module a particular 
“step” was written to describe the necessary construction 
and verification tasks. When the step was run, all files and 
their version numbers used in the execution of the step 
were recorded. A data-base was kept which could be queried 
for the steps that had been run and the steps that had to 
be run if any sub-module (and hence archive file) was 
changed. The management system provides an up-to-date 
view of the design progress and can remotely execute jobs 
on vacant Lisp machines. Using a history of previous job 
times, it can predict the time to completion of a given 
tapeout run. 


To create and check the entire Ivory physical data-base 
takes 30 Lisp CPU days. By using machines in parallel over 
the network, this can be done in 3-4 days. While this might 
seem a long time, this is the time to create a totally new 
physical data-base. The incremental time to produce a new 
chip after a typical ECO is on the order of hours. 


8. Summary 


Currently, the NS design system is also being used in Sym- 
bolics for the board level design of products based on Ivory, 
gate array design and other internal product designs. 


The tools developed to design Ivory comprised approximately 
one third of the total design effort. Without such tools, it is 
unlikely that the design of a chip of the complexity of Ivory 
would have been successful at first silicon. Lisp is the 
design language and implementation language for the entire 
project. By designing in Lisp, no intermediate languages 
have to be designed and no extraneous parsers written. The 
full richness of the Lisp software development available to 
bee system programmer is also available to the VLSI 
signer. 


All of the tools mentioned in this paper were written i 
New Flavors Lisp from scratch under he Symbolics Ganiers 
7 operating system by various of the authors of this paper. 
The NS system totals roughly 50K lines of code. The 
ee e Aig ee is bie from the object-oriented ap- 
proach which provides for modulari ili 
pie. odularity, reusability and exten- 
On the basis of the wide range of design activiti 

. . . ti 
ported, the intimate integration of the tools, the “anal ee 
gramming team size and the complexity of chip designed, 
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